Architektura Event Sourcing: Hluboký ponor do systémů ukládání doménových událostí

Event Sourcing je architektonický vzor, kde je stav aplikace určen posloupností událostí. Namísto ukládání aktuálního stavu entity trváme na řadě neměnných událostí, které představují změny dané entity. Tento blogový příspěvek podrobně prozkoumá architekturu Event Sourcing se zaměřením konkrétně na systémy ukládání doménových událostí.

Co je Event Sourcing?

V tradičních systémech je aktuální stav entity přímo uložen v databázi. Když dojde k aktualizaci, existující záznam je upraven nebo přepsán. Tento přístup funguje dobře pro mnoho aplikací, ale má omezení, když:

• Auditování a sledování historie jsou zásadní.
• Je třeba rekonstruovat složité přechody stavů.
• Je vyžadována propagace dat v reálném čase a architektury řízené událostmi.

Event Sourcing řeší tato omezení ukládáním každé změny stavu jako neměnné události. Tyto události jsou trvale uloženy v úložišti událostí pouze pro přidávání. Pro rekonstrukci aktuálního stavu entity jsou události přehrávány v pořadí, v jakém se staly. Představte si to jako účetní knihu, kde je zaznamenána každá transakce a zůstatek se vypočítá sečtením všech transakcí.

Klíčové koncepty

• Doménová událost: Fakt představující něco, co se stalo v doméně. Je to neměnný záznam o změně stavu. Příklady zahrnují OrderCreated, OrderShipped, PaymentReceived.
• Úložiště událostí: Datové úložiště pouze pro přidávání, optimalizované pro ukládání a načítání doménových událostí. Poskytuje mechanismy pro trvalé uchovávání, načítání a odběr událostí.
• Obslužné rutiny událostí: Komponenty, které reagují na doménové události. Mohou aktualizovat modely pro čtení, spouštět externí integrace nebo provádět jiné akce.
• Modely pro čtení: Denormalizované reprezentace dat optimalizované pro specifické vzory dotazů. Jsou aktualizovány obslužnými rutinami událostí a poskytují zobrazení dat pouze pro čtení.
• Snímkování: Technika používaná k optimalizaci rekonstrukce stavu periodickým ukládáním aktuálního stavu entity. Při rekonstrukci stavu systém načte nejnovější snímek a přehraje pouze události, ke kterým došlo po pořízení snímku.

Výhody Event Sourcing

Event Sourcing nabízí několik výhod oproti tradičním architekturám CRUD (Create, Read, Update, Delete):

• Kompletní auditní stopa: Každá změna stavu je zaznamenána jako událost, která poskytuje komplexní historii dat aplikace. To je neocenitelné pro auditování, ladění a dodržování předpisů.
• Časové dotazy: Možnost dotazovat se na stav entity v libovolném časovém bodě. To umožňuje historickou analýzu a reporting. Můžete například určit počet objednávek zadaných v konkrétním regionu v konkrétní den.
• Zjednodušené ladění: Opakováním událostí můžete znovu vytvořit jakýkoli minulý stav aplikace, což usnadňuje identifikaci a opravu chyb.
• Vylepšený výkon pro určité operace: Zatímco rekonstrukce stavu může být pomalejší, aktualizace modelů pro čtení může být vysoce optimalizována pro specifické vzory dotazů.
• Architektura řízená událostmi: Event Sourcing se přirozeně shoduje s architekturami řízenými událostmi, což umožňuje šíření dat v reálném čase a integraci s jinými systémy.
• Snadnější vývoj: Přidávání nových funkcí nebo úprava stávajících je často snazší, protože můžete jednoduše přidat nové obslužné rutiny událostí, aniž byste ovlivnili stávající datový proud událostí.
• Vylepšená škálovatelnost: Distribuce zpracování událostí mezi více uzlů může zlepšit škálovatelnost a odolnost.

Výzvy Event Sourcing

Event Sourcing také představuje některé výzvy, které je třeba pečlivě zvážit:

• Složitost: Implementace Event Sourcing vyžaduje odlišné myšlení a hlubší porozumění modelování domény a principům řízeným událostmi.
• Eventual Consistency: Modely pro čtení jsou eventual consistent s úložištěm událostí, což může způsobit zpoždění a nekonzistence v uživatelském rozhraní. Je třeba implementovat strategie pro řešení eventual consistency, jako je optimistické zamykání nebo kompenzační transakce.
• Verzování událostí: S vývojem aplikace se může změnit struktura doménových událostí. Je třeba implementovat strategie pro řešení verzování událostí, jako je migrace událostí nebo vývoj schématu, aby byla zajištěna zpětná kompatibilita.
• Rekonstrukce stavu: Rekonstrukce stavu entity opakováním událostí může být časově náročná, zejména u entit s velkým počtem událostí. Snímkování může pomoci tento problém zmírnit.
• Výběr správného úložiště událostí: Výběr vhodného úložiště událostí, které splňuje požadavky aplikace na výkon, škálovatelnost a spolehlivost, je zásadní.

Systémy ukládání doménových událostí: Srovnávací přehled

1. Relační databáze (SQL)

Relační databáze, jako jsou PostgreSQL, MySQL a SQL Server, lze použít jako úložiště událostí. I když nabízejí vlastnosti ACID (Atomicity, Consistency, Isolation, Durability) a silnou konzistenci dat, nemusí být nejefektivnější volbou pro zpracování událostí s vysokou propustností.

Výhody:

• Vlastnosti ACID: Zajišťuje integritu a konzistenci dat.
• Vyspělá technologie: Dobře zavedená technologie s rozsáhlými nástroji a podporou.
• Znalost: Většina vývojářů je obeznámena s relačními databázemi.
• Silná konzistence: Poskytuje silné záruky konzistence.

Nevýhody:

• Úzká hrdla výkonu: Mohou se stát úzkým hrdlem výkonu pro datové proudy událostí s vysokým objemem.
• Výzvy vývoje schématu: Zpracování změn schématu může být složité a vyžaduje pečlivé plánování.
• Omezení škálovatelnosti: Škálování relačních databází může být náročné, zejména pro pracovní zátěže náročné na zápis.
• Není optimalizováno pro operace pouze pro přidávání: Relační databáze nejsou specificky navrženy pro operace pouze pro přidávání, což může ovlivnit výkon.

Příklad implementace (PostgreSQL):

Vytvořte tabulku pro ukládání doménových událostí:

            CREATE TABLE events (
  event_id UUID PRIMARY KEY,
  aggregate_id UUID NOT NULL,
  event_type VARCHAR(255) NOT NULL,
  event_data JSONB NOT NULL,
  created_at TIMESTAMP WITHOUT TIME ZONE NOT NULL DEFAULT (NOW() AT TIME ZONE 'utc')
);

            

              
                Copy
              
            
          

Vložte novou událost:

            INSERT INTO events (event_id, aggregate_id, event_type, event_data)
VALUES (uuid_generate_v4(), 'a1b2c3d4-e5f6-7890-1234-567890abcdef', 'OrderCreated', '{"orderId": "ORD-123", "customerId": "CUST-456", "amount": 100}');

            

              
                Copy
              
            
          

2. NoSQL databáze

NoSQL databáze, jako jsou MongoDB, Cassandra a Couchbase, nabízejí větší flexibilitu a škálovatelnost ve srovnání s relačními databázemi. Jsou vhodné pro zpracování datových proudů událostí s vysokým objemem, ale mohou poskytovat slabší záruky konzistence dat.

Výhody:

• Škálovatelnost: Navrženo pro horizontální škálovatelnost a zvládne velké objemy dat.
• Flexibilita: Bezschémové nebo flexibilní schéma umožňuje snadnější verzování událostí.
• Výkon: Optimalizováno pro operace čtení a zápisu s vysokou propustností.
• Nákladově efektivní: Může být nákladově efektivnější než relační databáze pro určité pracovní zátěže.

Nevýhody:

• Eventual Consistency: Může poskytovat slabší záruky konzistence dat ve srovnání s relačními databázemi.
• Složitost: Vyžaduje hlubší porozumění konceptům NoSQL databází a technikám modelování dat.
• Vyspělost: Některé NoSQL databáze jsou méně vyspělé než relační databáze.
• Omezení dotazování: Možnosti dotazování mohou být omezené ve srovnání s relačními databázemi.

Příklad implementace (MongoDB):

Uložte doménové události do kolekce:

            {
  "event_id": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
  "aggregate_id": "f1g2h3i4-j5k6-l7m8-n9o0-p1q2r3s4t5uv",
  "event_type": "OrderCreated",
  "event_data": {
    "orderId": "ORD-123",
    "customerId": "CUST-456",
    "amount": 100
  },
  "created_at": ISODate("2023-10-27T10:00:00.000Z")
}

            

              
                Copy
              
            
          

3. Specializované úložiště událostí

Specializované úložiště událostí, jako jsou EventStoreDB a AxonDB, jsou navrženy speciálně pro Event Sourcing. Poskytují funkce, jako je úložiště pouze pro přidávání, verzování událostí a správa datových proudů. Tyto databáze jsou obvykle nejlepší volbou, pokud to s event sourcingem myslíte vážně.

Výhody:

• Optimalizováno pro Event Sourcing: Navrženo speciálně pro event sourcing s funkcemi, jako je úložiště pouze pro přidávání, správa datových proudů a verzování událostí.
• Vysoký výkon: Optimalizováno pro zpracování událostí s vysokou propustností.
• Zpracování Eventual Consistency: Vestavěné mechanismy pro zpracování eventual consistency.
• Správa datových proudů: Zjednodušuje správu a dotazování datových proudů událostí.

Nevýhody:

• Závislost na dodavateli: Může zavést závislost na dodavateli.
• Náklady: Může být dražší než jiné možnosti.
• Křivka učení: Vyžaduje naučení se nové technologii.
• Omezené přijetí: Méně rozšířené než relační a NoSQL databáze.

Příklad implementace (EventStoreDB):

EventStoreDB používá datové proudy k ukládání událostí. Události můžete připojit k datovému proudu pomocí klientské knihovny EventStoreDB.

4. Fronty zpráv (Kafka, RabbitMQ)

Fronty zpráv, jako jsou Apache Kafka a RabbitMQ, lze použít jako úložiště událostí, zejména ve spojení s rámci pro zpracování datových proudů. Poskytují vysokou propustnost, škálovatelnost a odolnost proti chybám, díky čemuž jsou vhodné pro rozsáhlé aplikace řízené událostmi. Obecně se však používají spíše jako přechodný transportní mechanismus než trvalé úložiště.

Výhody:

• Vysoká propustnost: Navrženo pro zpracování zpráv s vysokou propustností.
• Škálovatelnost: Vysoce škálovatelné a zvládne velké objemy událostí.
• Odolnost proti chybám: Vestavěné mechanismy odolnosti proti chybám.
• Zpracování v reálném čase: Umožňuje zpracování událostí v reálném čase.

Nevýhody:

• Složitost: Vyžaduje hlubší porozumění konceptům fronty zpráv a rámcům pro zpracování datových proudů.
• Trvanlivost dat: Trvanlivost dat je třeba pečlivě konfigurovat.
• Opakování událostí: Opakování událostí může být složitější než u specializovaných úložišť událostí.
• Záruky řazení: Záruky řazení mohou být omezené v závislosti na konfiguraci.

Příklad implementace (Apache Kafka):

Publikujte doménové události do tématu Kafka:

            // Producer configuration
Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

Producer<String, String> producer = new KafkaProducer<>(props);

// Create a record
ProducerRecord<String, String> record = new ProducerRecord<>("order-events", "ORD-123", "{"event_type": "OrderCreated", "customerId": "CUST-456", "amount": 100}");

// Send the record
producer.send(record);

producer.close();

            

              
                Copy
              
            
          

5. Cloudové úložiště událostí

Poskytovatelé cloudu nabízejí spravované služby úložiště událostí, jako jsou Azure Event Hubs, AWS Kinesis a Google Cloud Pub/Sub. Tyto služby poskytují škálovatelnost, spolehlivost a snadné použití, díky čemuž jsou dobrou volbou pro cloudové aplikace.

Výhody:

• Škálovatelnost: Vysoce škálovatelné a zvládne velké objemy událostí.
• Spolehlivost: Vestavěná spolehlivost a odolnost proti chybám.
• Snadné použití: Spravované služby zjednodušují nasazení a údržbu.
• Integrace: Bezproblémová integrace s dalšími cloudovými službami.

Nevýhody:

• Závislost na dodavateli: Zavádí závislost na dodavateli.
• Náklady: Může být dražší než řešení spravovaná sami.
• Latence: Síťová latence může ovlivnit výkon.
• Kontrola: Menší kontrola nad základní infrastrukturou.

Úvahy o výkonu

Výkon je kritickým faktorem při výběru systému ukládání doménových událostí. Zde je několik úvah o výkonu, které je třeba mít na paměti:

• Propustnost zápisu: Schopnost zvládnout velký objem příchozích událostí.
• Latence čtení: Doba potřebná k načtení událostí a rekonstrukci stavu entity.
• Souběžnost: Schopnost zvládnout souběžné operace čtení a zápisu.
• Kapacita úložiště: Množství úložiště potřebné k ukládání událostí.
• Síťová latence: Latence mezi aplikací a úložištěm událostí.

Chcete-li optimalizovat výkon, zvažte následující techniky:

• Dávkování: Dávkování událostí před jejich zápisem do úložiště událostí může zlepšit propustnost zápisu.
• Ukládání do mezipaměti: Ukládání často přistupovaných událostí do mezipaměti může snížit latenci čtení.
• Snímkování: Snímkování může snížit počet událostí, které je třeba přehrát při rekonstrukci stavu entity.
• Indexování: Indexování událostí na základě ID agregátu a dalších relevantních atributů může zlepšit výkon dotazů.
• Fragmentace: Fragmentace úložiště událostí mezi více uzlů může zlepšit škálovatelnost a výkon.

Integrita dat

Integrita dat je v Event Sourcing prvořadá. Je zásadní zajistit, aby události byly trvale uloženy spolehlivě a ve správném pořadí. Zde je několik strategií pro udržování integrity dat:

• Transakce: Používejte transakce, abyste zajistili, že události budou zapsány atomicky do úložiště událostí.
• Idempotence: Navrhněte obslužné rutiny událostí tak, aby byly idempotentní, což znamená, že mohou zpracovávat stejnou událost vícekrát bez způsobení nezamýšlených vedlejších účinků.
• Optimistické zamykání: Používejte optimistické zamykání, abyste zabránili souběžným aktualizacím stejného agregátu.
• Ověření událostí: Ověřte události před jejich trvalým uložením do úložiště událostí, abyste zajistili, že jsou platné a konzistentní.
• Kontrolní součty: Vypočítejte kontrolní součty událostí a uložte je spolu s událostmi. Ověřte kontrolní součty při načítání událostí, abyste se ujistili, že nebyly poškozeny.

Verzování událostí

S vývojem aplikace se může změnit struktura doménových událostí. Zpracování verzování událostí je zásadní pro zajištění zpětné kompatibility a prevenci ztráty dat. Zde je několik strategií pro zpracování verzování událostí:

• Upcasting událostí: Transformujte starší verze událostí na nejnovější verzi při jejich čtení z úložiště událostí.
• Vývoj schématu: Vyvíjejte schéma událostí v průběhu času přidáváním nových polí nebo úpravou stávajících. Zajistěte, aby starší verze událostí mohly být stále správně zpracovány.
• Migrace událostí: Migrujte starší události na nejnovější verzi schématu. To lze provést jako proces na pozadí.

Příklady z reálného světa

Event Sourcing se používá v různých odvětvích a aplikacích. Zde je několik příkladů z reálného světa:

• E-commerce: Sledování historie objednávek, změn inventáře a aktivity zákazníků. Globální platforma elektronického obchodu by například mohla používat Event Sourcing ke sledování objednávek z různých zemí, zpracování převodů měn a správě inventáře napříč více sklady.
• Bankovnictví: Zaznamenávání transakcí, sledování zůstatků na účtech a auditování finančních aktivit. Nadnárodní banka by mohla používat Event Sourcing ke sledování transakcí napříč různými pobočkami a měnami, čímž by zajistila kompletní auditní stopu.
• Hraní her: Sledování akcí hráčů, změn stavu hry a historie událostí. Online hry pro více hráčů často používají Event Sourcing k udržení konzistentního stavu hry napříč více hráči a servery.
• Řízení dodavatelského řetězce: Sledování pohybů produktů, úrovní inventáře a harmonogramů dodávek. Globální logistická společnost může používat Event Sourcing ke sledování zásilek napříč různými zeměmi, zpracování celního odbavení a správě harmonogramů dodávek.

Výběr správného systému ukládání: Rozhodovací matice

Abyste se mohli rozhodnout, který systém ukládání doménových událostí je pro vaši aplikaci ten správný, zvažte následující rozhodovací matici:

Akční poznatky

Zde je několik akčních poznatků pro implementaci Event Sourcing:

• Začněte v malém: Začněte s malou, dobře definovanou doménou, abyste získali zkušenosti s Event Sourcing, než ji použijete na větší a složitější domény.
• Zaměřte se na doménu: Pečlivě modelujte svou doménu a identifikujte klíčové doménové události.
• Vyberte správný systém ukládání: Vyberte úložiště událostí, které splňuje požadavky vaší aplikace na výkon, škálovatelnost a konzistenci dat.
• Implementujte verzování událostí: Plánujte verzování událostí od začátku, abyste zajistili zpětnou kompatibilitu.
• Monitorujte výkon: Monitorujte výkon svého úložiště událostí a obslužných rutin událostí, abyste identifikovali potenciální úzká hrdla.
• Automatizujte nasazení: Automatizujte nasazení a správu své infrastruktury Event Sourcing.
• Zvažte kompromisy: Event Sourcing zahrnuje kompromisy. Uvědomte si, že se objevují složitosti pro výhody získané z tohoto vzoru.

Závěr

Event Sourcing je výkonný architektonický vzor, který nabízí řadu výhod, včetně kompletní auditní stopy, časových dotazů a vylepšeného výkonu pro určité operace. Představuje však také výzvy, které je třeba pečlivě zvážit, jako je složitost, eventual consistency a verzování událostí. Pečlivým výběrem systému ukládání doménových událostí a implementací osvědčených postupů můžete úspěšně využít Event Sourcing k vytváření škálovatelných, odolných a auditovatelných aplikací.

Tato příručka poskytla přehled Event Sourcing a několika oblíbených systémů ukládání doménových událostí. Vyberte si nejlepší systém, který bude v souladu s konkrétními potřebami vašich projektových požadavků.

Pamatujte, že tento obsah je určen pro globální publikum, takže si přizpůsobte a aplikujte koncepty na své jedinečné okolnosti a kulturní kontext. Principy Event Sourcing jsou univerzální, ale implementace se může lišit v závislosti na vašich konkrétních potřebách a zdrojích.